【レポート】AWSのマネージドサービスを活かした Kubernetes 運用とAmazon EKS によるクラスタのシングルテナント戦略について #AWSSummit

こんにちは、城岸です。

2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。 本記事は「AWSのマネージドサービスを活かした Kubernetes 運用とAmazon EKS によるクラスタのシングルテナント戦略について」のセッションレポートになります。

セッション概要

スピーカー：足立 紘亮氏 （freee株式会社 プロダクト基盤 SRE）

セッション名：AWSのマネージドサービスを活かした Kubernetes 運用とAmazon EKS によるクラスタのシングルテナント戦略について

freeeにはAWSの運用のノウハウやデータが蓄積されており、K8sも複数のマネージドサービスと組み合わせて運用しています。 これまで使い続けてきたRDSやS3、LBやRoute53などをそのまま活かしつつ、K8sのエコシステムも利用できるのはK8sをAWS上で利用する大きなメリットとなります。 本セッションではこれまでK8sをAWSで運用してきて得られた知見とEKSを選択するメリット、またBlast Radiusへの考慮と権限委譲を目的としたクラスタのシングルテナント戦略についてご紹介します。

レポート

マイクロサービス化により加速的に増えるSREチームの負荷。その負荷をを軽減させるためのヒント満載のセッションでした！ それではレポートをどうぞ。 ※途中でメモしきれなかった部分があります。。ので資料が公開され次第補完します。

freeeの開発組織について

• 開発チームは100人以上、1チームが2−10人（兼任することもある）
• SREチームは8人、全てのサービスを支える横断的なチーム
• SOC1 Type2を取得（上場企業への導入に対応）

インフラリソースのコード化

新規プロダクトの立ち上げ時に実施する作業

• SREチームが実施する作業
  • AWSリソースの作成、開発環境の整備
  • ネットワーク、LB、ASG、デプロイ環境整備、DB追加、Route53、セキュリティ、IAMロールなど
• 開発チーム
  • アプリケーション開発、デプロイ
• 権限はSREが強い、そのためデプロイの失敗などはSREに問い合わせが入る。
  • アクセス数が増加して耐えきれません、DBの負荷が。。などなど。何でも屋になりがち
• 目先のタスクに追われるSRE

• マイクロサービスの流れがさらにそれを加速させる

そのために、

インフラリソースのコード化

• freeeを支えるインフラ系ツール
  • Docker
  • Kubernetes
  • Terraform
• Docker
  • 全てのアプリケーションをコンテナ化
  • 多様な言語フレームワークの複雑さを吸収（デプロイ周りの環境などSREの負荷が軽減される
• Kubernetes
  • コンテナを動かすための環境
  • アプリケーションの動作環境をマニュフェストとしてコード化
  • 宣言的にデプロイ、オートスケール 、オートヒーリング
• Terraform
  • AWSリソースのコード化
  • 宣言的にリソースを作成することができる

コード化されるとSREとアプリチームのコミュニケーションが変わる

• コード化されていない世界
  • SREに頼むしかない（権限がない、構成を理解できていない、知識がない、怖いなど）
• コード化された世界
  • 開発チームがコードを作成、SREチームは開発チームが作成したコードをレビュ

開発チームにサービスの運用をお任せできる！かもしれない

シングルテナントで権限を分離してクラスタの運用をお任せする

• シングルテナントのメリット
  • 障害の影響範囲が小さい
  • セキュリティの境界線の明確化
  • アップデート作業がしやすい
• シングルテナントのデメリット
  • 単純に管理するクラスタが増える
  • インスタンスの数も増える
  • アップデート作業がしにくい
• 障害の影響範囲が小さい
  • 何かしらも問題があると（オペミス、バグ）全サービスダウンの可能性
  • 運用の難易度が高く、チャレンジしずらい
• セキュリティの境界線の明確化
  • 上場企業に導入するために相応のセキュリティ対策が必要
  • マルチテナントではセキュリティの分割が難しい
    • SGの分割が不可
    • プロダクト間でEC2は共通
    • プロダクト間でノードグループを分割すれば対応可能であるがそのための仕組み作りが必要
• アップデート作業がしやすい
  • クラスタ全体のアップデートはミスをすれば全プロダクトになるから作業がしにくい
  • シングルテナントであればその範囲は作業がしやすい

クラスタの運用をお任せをするならシングルテナント

EKSをマネージドサービスと組み合わせてクラスタの運用コストを抑える

• k8sにどこまで任せる？
  • k8sに何でもやらせようとしない。k8sで様々なリソースを作成し難しい運用にすると開発チームが対応できず結局SREチームにに戻ってくるから
  • AWSのマネージドサービスを積極的に利用
  • k8sはアプリケーションを動かすことだけに利用する
  • マネージドサービスとK8sの得意分野が生き得る

シンプルな構成にすることで、新しいパーツが出てきたときに試しやすい。AppMesh/Istioなど シンプルな構成だから影響範囲を最小限に一部のテナントで導入なども可能

マルチテナントからシングルテナントなEKSに移行した実例

• クラスタ総数26をEKSに移行

• クラスタの移行で活躍したツール

  • Terraform
    • 開発チームはPRを作成し、SREのレビューをへてApply
  • kubectl
  • eksctl
    • 開発チームはPRを作成し、SREのレビューをへてApply
  • helm
    • 開発チームはChartを作成しPR、SREのレビューをへてApply
  • eksclst
    • 内製ツール
    • 標準的なリソース（aws-authなど）をテンプレート化
• 移行
  • Route53のweighted routingによりトラフィックを徐々に新しいクラスタに流し込む
• プロジェクト成功の要因
  • 開発チームのk8sへの意欲が高かった

SREチームの負荷を軽減するために

• インフラリソースのコード化
• シングルテナント化がおすすめ
• マネージドサービスをうまく使う
• 開発チームに高い意欲が必要

常にベターを考えがら運用を改善していくことが重要

まとめ

EKSを利用するにあたりSREチームの負荷を下げるヒント満載のセッションでした。

ただそれと同時に「この開発チームのスキル高すぎやしませんか？普通の開発チームはTerraformとかk8sのYamlファイルかけなくないですか？」という思いが溢れましたw